AD-A238  936 


8-!.'  T-S 

Jil!  *_•  ;  ■  'j }U  „<J 

Jjj t i* Icat  1  utL- 


*f - _ 

‘‘i5!-r  lout  Ion/ 


FEASIBILITY  ANALYSIS  REPORT 
AS  TO  THE 
DEVELOPMENT  OF  A 
JOINT  OPERATIONS 
INTEROPERABILITY  SYSTEM 
FOR  MARINE  CORPS  C3I 
SYSTEMS 

Topic  Number:  N90-022 


"liability  Ccd»o 


ist  j  Special 


:W-\ 


Phase  I  Final  Technical  Report 


31  May  1991 


Prepared  under  Contract  Number  DAAL03-91-C-0004  For 
U.  S.  Army  Research  Office 
P.O.  Box  12211 
Research  Triangle  Park,  NC 
27709-2211 

MiTech,  Inc.,  2361  Jefferson  Davis  Highway,  Suite  UL-336, 
Arlington,  Virginia  22202 


91-05323 

■HUM 


nn 


AD-A238  936  rATI0N  PAGE 


Form  Approved 
OMB  NO.  0704-01B8 


mMmi 
m.  M« 


I  »w|  Hu  iHmw  et  iMimuiiL  »wio>«n«Nniwa  ; 

w.  IQ  wmM)Hii  iummnin  Uniat.  Hwao«»«i  tor  w*owmwi  Omumw  tat  Wrpom.  1215  r 
wet  mm  >g«nm  mu  »i<ih.  r»p«r— o»*  iw  Auction  miwimi  tuftnmiwim.  oc  2M1. 

1.AGENCY  USE  ONLY  (Zcawc  M»n*7  I  2.  KfcPUHl  DATE  3.  REPORT  TV  Ft  AND  OATES  COVEREO 

_ _ _ '  I  31  May  1991 _ Final  Technical  Report  lHov90-30Apr91 


4.  me  AND  SUBTITLE 

Joint  Operations  Interoperability  System  for  Marine 
Corps  C3I  Systens 

*.  authors)  fvrTn 

R.  K.  Diehl  U  l  I  U 

_ ELECT* jm 

7.  PERFORMING  ORGANIZATION  NAME(S)  ANO  4^ttESS(Ef{j|_|  g  ]9S]  1  I 

MiTech,  Inc.  j  1 

820  1st  Street,  N.E.  p  BV 

Suite  600  ^ 

Washington,  D.C.  20002 

9.  SPONSORING /MONITORING  AGENCY  NAME(S)  ANO  AOORCSS(ES) 

U.  S.  Army  Research  Office 
|  P.  0.  Box  12211 

Research  Triangle  Park,  NC  27709-2211 


|S.  FUNDING  NUMBERS 


[8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


10.  SPONSORING /MONITORING 
AGENCY  REPORT  NUMBER 


A&)  <2  i  .i-€c^6r 


11.  SUPPLEMENTARY  NOTES 

The  view,  opinions  and/or  findings  contained  in  this  report  are  those  of  the 
author (s)  and  should  not  be  construed  as  an  official  Department  of  the  Army 
position,  policy,  or  decision,  unless  so  designated  by  other  documentation. 

12a.  DISTRIBUTION/ AVAILABILITY  STATEMENT  12b.  DISTRIBUTION  CODE 

Approved  for  public  release;  distribution  unlimited. 


13.  ABSTRACT  (Maximum  200  words) 

^-This  report  provides  the  final  results  of  the  SBIR,  Phase  I,  feasibility  analysis 
into  the  development  of  the  Joint  Operations  Interoperability  System  for  Marine 
Corps  C3I  Systems.  The  objective  of  this  effort  was  to  conduct  and  document  an 
analysis  based  on  the  Marine  Tactical  Systems  (MTS)  protocol,  to  determine  the 
feasibility  of  developing  a  bi-directional  Data  Link  Interface  System  that  could 
Interface  multiple  non-MTS  digital  data  link  protocols  to  the  MTS  protocol,  and  be 
readily  adapted  to  changing  interface  requirements.  The  conclusion  of  this 
analysis  was  that  the  development  of  the  Data  Link  Interface  System  concept,  as  . 
documented  in  this  report,  Was  both  technically  feasible  with  existing  technology, 
and  would  drastically  reduce  the  life-cycle-cost  of  system  interoperability. 


1 14.  SUBJECT  TEAMS 


Interoperability,  Data  Link,  Protocol,  DLIS,  DBMS 


IS.  NUMBER  OF  PAGES 

33 

I  k  PRICE  cdoi 


OF  REPORT 
UNCLASSIFIED 

NSN  754001-280-5500 


OF  THIS  MSI 
UNCLASSIFIED 


119.  SECURITY  CLASSIFICATION  1 20.  UMTTAT10N  OF  ABSTRACT 
OF  ABSTRACT  I 


UNCLASSIFIED 


Standard  Form  298  (Rev  2  -?• 


GENERAL  INSTRUCTIONS  FOR  COMPLETING  SF  298 

The  Report  Documentation  Page  (ROP)  is  used  in  announcing  and  cataloging  reports.  It  is  important 
that  this  information  be  consistent  with  the  rest  of  the  report,  particularly  the  cover  and  title  page. 
Instructions  for  filling  in  each  block  of  the  form  follow,  it  is  important  to  stay  within  the  lines  to  meet 
optical  scanning  requirements. 


Block  1.  Aoencv  Use  Only  (Leave  blank). 

Block  2.  Report  Date.  Full  publication  date 
including  day,  rponth,  and  year,  if  available  (e.g.  1 
Jan  88).  Must  cite  at  least  the  year. 

Block  3.  Type  of  Report  and  Dates  Covered. 
State  whether  report  is  interim,  final,  etc.  If 
applicable,  enter  inclusive  report  dates  (e.g.  1 0 
Jun87-30Jun88). 

Block  4.  Title  and  Subtitle.  A  title  is  taken  from 
the  part  of  the  report  that  provides  the  most 
meaningful  and  complete  information.  When  a 
report  is  prepared  in  more  than  one  volume, 
repeat  the  primary  title,  add  volume  number,  and 
include  subtitle  for  the  specific  volume.  On 
classified  documents  enter  the  title  classification 
in  parentheses. 

Blocks.  Funding  Numbers.  To  include  contract 
and  grant  numbers;  may  include  program 
element  number(s),  project  number(s),  task 
numbers),  and  work  unit  number(s).  Use  the 
following  labels: 


c  - 

Contract 

PR  - 

Project 

G  - 

Grant 

TA  - 

Task 

PE  - 

Program 

WU  - 

Work  Unit 

Element 

Accession  No. 

Block  6.  Authorfs).  Name(s)  of  person(s) 
responsible  for  writing  the  report,  performing 
the  research,  or  credited  wjth  the  content  of  the 
report.  If  editor  or  compiler,  this  should  follow 
the  name(s). 

Block  7.  Performing  Organization  NametsV  and 
Addressees).  Self-explanatory. 

Block  8.  Performing  Organization  Report  . 
Number.  Enter  the  unique  alphanumeric  report 
numberfs)  assigned  by  the  organization 
performing  the  report 

Block  9.  SponsorinqfMonitorino  Aoencv  Namefs) 
and  Address(es).  Self-explanatory. 

Block  10.  Sponsorino/Monitorino  Aoencv 
Report  Number.  (If  known) 

MO*  11-  Supplementary  Notes.  Enter 
information  not  included  elsewhere  such  as: 
Prepared  in  cooperation  with...;  Trans,  of...;  To  be 
published  in....  When  a  report  is  revised,  include 
a  statement  whether  the  new  report  supersedes 
or  supplements  the  older  report 


Block  12a.  Distribution/Availabilitv  Statement 
Denotes  public  availability  or  limitations.  Cite  any 
availability  to  the  public  Enter  additional 
limitations  or  special  markings  in  all  capitals  (e.g. 
NOFORN,  REL.  ITAR). 

DOO  -  See  DoDD  5230.24.  'Distribution 
Statements  on  Technical  • 

Documents." 

DOE  -  See  authorities. 

NASA  -  See  Handbook  NHB  2200.2. 

NT1S  -  Leave  blank. 


Block  12b.  Distribution  Code! 

DOD  -  Leave  blank. 

DOE  -  Enter  DOE  distribution  categories 

from  the  Standard  Distribution  for  - 
Unclassified  Scientific  and  Technical 
Reports. 

NASA  -  Leave  blank. 

NT1S  -  Leave  blank. 

Block  13.  Abstract  Include  a  brief  (Maximum 
200  words)  factual  summary  of  the  most 
significant  information  contained  in  the  report. 

Block  14.  Subject  Terms.  Keywords  or  phrases 
identifying  major  subjects  in  the  report. 

r  - 

Block  15.  Number  of  Pages.  Enter  the  total 
number  of  pages. 

Block  16.  Price  Code.  Enter  appropriate  price , 
code  (ACTS  only). 

Blocks  17.- 19.  Security  Gasifications.  Self- 
explanatory.  Enter  U.S.  Security  Classification  in 
accordance  with  U.S.  Security  Regulations  (i.e., 
UNCLASSIFIED).  If  form  contains  classified 
information,  stamp  classification  on  the  top  and 
bottom  of  the  page. 


Block  20.  Limitation  of  Abstract.  This  block  must 
be  completed  to  assign  a  limitation  to  the 
abstract.  Enter  either  UL  (unlimited)  or  SAR  (same 
as  report).  An  entry  in  this  block  is  necessary  if 
the  abstract  is  to  be  limited.  If  blank,  the  abstract 
is  assumed  to  be  unlimited. 


Standard  Form  298  Back  (Rev.  2-B9) 


FEASIBILITY  ANALYSIS  REPORT 
AS  TO  THE 
DEVELOPMENT  OF  A 
JOINT  OPERATIONS 
INTEROPERABILITY  SYSTEM 
FOR  MARINE  CORPS  C3I 
SYSTEMS 

Topic  Number:  N90-022 
Phase  I  Final  Technical  Report 
31  May  1991 


Prepared  under  Contract  Number  DAAL03-91  -C-0004  For 
U.  S.  Army  Research  Office 
P.O.  Box  12211 
Research  Triangle  Park,  NC 
27709-2211 


MiTech,  Inc.,  2361  Jefferson  Davis  Highway,  Suite  UL-336, 
Arlington,  Virginia  22202 


TABLE  09  CONTENTS 


Eaca  Title  Page 

1  INTRODUCTION  .  3 

1.1  Identification  of  the  Problem  .  3 

1.2  Significance  of  the  Solution .  3 

1.3  Objectives  of  Analysis  .  4 

1.4  Hypothesis  of  Feasibility  .  4 

1.5  Technical  Approach  .  4 

2  DISCUSSION  5 

2.1  Discussion  Basis  . 5 

2.1.1  Information  Versus  Data  .  5 

2.1.2  Protocol  Model  . .  5 

2.1.3  Protocol  Rule .  7 

2.1.4  Field .  7 

2.1.5  Chain .  7 

2.1.6  Set  .  7 

2.1.7  Group .  8 

2.1.8  Message  .  8 

2.1.9  Repeatability  .  8 

2.1.10  Mandatory  .  8 

2.1.11  Optional  .  9 

2.1.12  Conditional  .  9 

2.1.13  Fixed-Format  .  9 

2.1.14  Variable-Format  .  9 

2.1.15  Character-Oriented  .  10 

2.1.16  Bit-Oriented  . .  10 

2.2  Hypothesis  Basis  .  10 

2.3  Hypothesis  .  11 

2.4  Data  Link  Interface  System  Processing  .  11 

2.5  Layer  7  -  Application  Layer  Analysis  .  13 

2.6  Layer  6  through  0  Analysis  .  14 

2.7  Application  Layer  Configuration  Interface  .  14 

2.8  Generation  Process  .  15 

2.9  Feasibility  Results  . .  16 

2.9.1  Low  Risk  . .  16 

2.9.2  Low  Life-Cycle-Cost  .  17 

3  DOCUMENTATION  .  18 

3.1  Intermediate  Reports  .  18 

3.2  Research  Sources  .  18 

4  DEMONSTRATION  MODEL  .  19 

4.1  Demonstration  Objective  .  19 

4.2  Message  Formats  .  19 

4.3  Demonstration  Functions  .  19 

4.4  Adapability  and  Maintainability  .  22 

4.4.1  List  Files  for  Selection  Type  Fields  .  22 

4.4.2  Generic  Subroutines  for  Numeric  Type  Fields  ....  22 

4.4.3  Data  Files  for  Chains,  Sets  and  Groups  .  23 

4.4.4  Data  Files  for  Message  Formats  .  23 

4.4.5  Data  Files  for  System  Configuration .  23 


1 


/ 


TABLE  OF  CONTENTS 

Para  Title  Ease 

4.5  Sample  1  Demonstration  Input/Output  .  24 

4.6  Sample  2  Demonstration  Input/Output  .  28 

5  SUMMARY  .  31 

5.1  Feasibility .  31 

5.2  Adaptability  and  Maintainability  .  31 

6  CONCLUSION .  32 

6.1  Feasible .  32 

7  RECOMMENDATIONS  .  32 

7.1  Continued  Development  .  32 

7.2  Standing  Working  Group  .  32 


2 


1.  INTRODUCTION 


1.1  Identification  of  the  Problem.  Although  much  effort  has 
been  expended  to  develop  Interoperability  among  the  services,  the 
situation  as  it  exists  today  requires  each  service  and  agency  to 
implement  a  large  variety  of  digital  data  link  network  interfaces 
in  each  of  its  tactical  data  systems.  The  development  and 
maintenance  of  each  of  these  different  digital  data  link 
interfaces  is  extremely  expensive  and  time  consuming.  In 
general,  each  tactical  data  system  is  independently  developed  and 
maintained  causing  additional  interoperability  problems  among  the 
tactical  data  systems  due  to  incompatible  versions. 

With  the  current  state  of  computer  technology,  it  should  now 
be  feasible  to  develop  a  single  digital  data  link  network 
interface  module,  consisting  of  hardware  and  software,  that 
could: 

a.  Be  integrated  into  any  tactical  data  system, 

b.  Be  capable  of  interfacing  multiple,  differing  digital 
data  link  networks, 

c.  Be  easily  adaptable  to  the  mix  of  digital  data  link 
networks  interfaced, 

d.  Be  easily  adaptable  to  the  variety  of  data  messages 
implemented  and  the  information  needs  of  the  tactical  data 
system, 

e.  Be  easily  and  inexpensively  maintained,  and 

f.  Be  responsive  to  the  needs  of  the  operational  facilities 
supported  by  the  tactical  data  systems. 

1.2  Significance  of  the  Solution.  The  importance  of  this 
development  would  be  a  significant  increase  in  the  responsiveness 
of  any  tactical  data  system  to  exchange  the  information  necessary 
to  the  proper  functioning  of  the  operational  facility,  and  a 
significant  decrease  in  the  cost  and  time  necessary  to  develop 
and  maintain  each  service  or  agency  capability  to  interoperate 
with  other  services  and  agencies,  and  to  intraoperate  within  each 
service  or  agency.  Upon  completion,  it  is  expected  that  this 
capability  would  be  rapidly  accepted  by  all  services  and  agencies 
to  provide  a  significant  benefit  to  the  Department  of  Defense  and 
other  departments  and  agencies. 
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1.3  Objectives  of  Analysis.  The  objectives  of  this 
feasibility  analysis  were: 

a.  To  conduct  an  analysis,  based  on  the  Marine  Tactical 
Systems  (MTS)  protocol,  to  determine  the  feasibility  of 
developing  a  Data  Link  Interface  System  (DLIS)  that  could 
interface  non-MTS  digital  data  link  protocols  to  the  MTS 
protocol,  and  be  easily  adapted  to  changing  interface 
requirements . 

b.  To  develop  a  demonstration  system  to  illustrate  the 
feasibility  of  the  DLIS  concept. 

1.4  Hypothesis  of  Feasibility.  Based  on  preliminary  analysis 
and  experience  in  the  development  and  implementation  of  many 
digital  data  link  protocols,  MiTech  hypothesized  that  the  Data 
Link  Interface  System  is  not  only  feasible,  but  also  has  the 
potential  to  solve  many  of  the  existing  interoperability  problems 
with  a  significant  cost  savings. 

1.5  Technical  Approach.  The  MiTech  technical  approach  and 
concept  of  the  Data  Link  Interface  System  functionality  is  based 
on  an  information  store-and-forward  technique,  totally 
independent  of  the  digital  data  links  being  implemented.  This 
allows  the  system  to  be  extremely  adaptable  to  changing  protocol 
requirements  and  allows  the  system  to  be  software  configurable  to 
the  users  needs. 
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DISCUSSION 


2.1  Discussion  Basis.  In  order  to  properly  discuss  the 
results  of  this  feasibility  analysis,  a  basic  format  for 
discussion  must  be  understood.  In  order  to  present  a  valid 
discussion  the  following  terms  and  basic  formats  are  provided: 

2.1.1  Information  Versus  Data.  Throughout  the  discussion 
of  the  Data  Link  Interface  System,  the  terms  information  and  data 
will  be  used  extensively.  To  make  the  discussion  understandable, 
the  terms  information  and  data  will  not  be  used  interchangeably. 
Information  is  a  "real-world"  representation  of  a  fact  or 
presence.  For  example,  the  fact  that  something  exists  and  has  a 
location  is  really  an  abstract  idea.  In  order  to  represent  this 
fact  in  an  information  base,  the  information  must  be  stored  in  a 
logical  manner  that  captures  the  meaning  of  the  information  not 
necessarily  comparable  to  the  simple  storage  of  the  data  that  is 
transmitted  or  received.  If  the  data  received  is  a  relative 
location,  range  and  bearing,  the  actual  information  received  is 
actually  the  location  of  the  entity  being  reported.  The  location 
of  the  entity  is  what  is  placed  in  the  information  base,  along 
with  other  information  that  makes  the  entity  location  information 
complete,  such  as,  the  effective  time  information,  the 
identification  of  the  entity,  and  the  uncertainty  of  the  location 
information.  Another  important  aspect  of  information  storage  is 
that  the  information  may  have  no  direct  basis  relative  to  the 
data  being  transmitted  and  received  and  can  be  standardized  for 
easy  table-driven  conversion/manipulation.  If  the  data  received 
is  10  Kilometers  (10KM)  for  a  distance,  the  information  stored 
may  actually  be  10000,  where  "Meters"  is  understood  from  the 
information  base  standardization.  This  conversion  is  easy  in 
that  the  conversion  factors  maintained  in  a  table  need  only 
relate  one  unit  of  measurement  to  the  information  base  standard 
and  the  information  base  doesn't  need  to  store  the  unit  of 
measure  data.  Later,  regardless  of  the  output  protocol,  the 
information  can  be  accessed  and  if  necessary  just  as  easily 
converted  to  that  protocols  requirements,  such  as  "Nautical 
Miles". 


2.1.2  Protocol  Model.  Throughout  this  discussion  a  model 
of  all  digital  data  link  protocols  will  be  used.  This  model 
allows  the  discussion  to  proceed  on  a  generic  basis  rather  than 
constantly  referring  to  specific  protocols.  The  model  selected 
is  the  same  model  used  throughout  the  design  plan  for  the  Marine 
Tactical  System  (MTS)  protocol.  This  generic  model  is  useful  in 
that  every  digital  data  link  protocol  can  ba  easily  transformed 
into  the  model  through  the  identification  of  services  and 
functions.  This  model  consists  of  the  seven-layer  International 
Standards  Organization  (ISO)  Reference  Model  for  Open  Systems 
Interconnection  (0SI)  with  the  addition  of  a  0-layer  Transmission 
Media  layer.  Table  2-1  provides  the  organization  and  services  of 
this  model. 
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T  able  2-1  Information  T  ransfer 


2.1.3  Protocol  Rule.  Throughout  the  documentation  for 
each  digital  data  link  protocol,  there  are  found  numerous  rules. 
These  rules  provide  the  framework  for  the  protocol,  and  must  be 
strictly  adhered  to  provide  interoperability.  These  rules  exist 
at  every  layer  of  the  protocol,  are  documented  inconsistently 
from  protocol  to  protocol,  and  unless  stated  otherwise  imply  a 
"no-more,  no-less"  option.  For  each  protocol,  the  overall 
collection  of  these  rules  are  probably  the  most  difficult  to 
understand  and  implement,  and  if  implemented  incorrectly  generate 
the  greatest  impact  on  interoperability. 

2.1.4  Field.  A  data  field  is  the  basic  syntactic 
building  block  of  digital  data  link  protocol  data.  It  has  a  very 
specific  format  and  generally  has  a  restricted  set  of  valid 
entries  or  values.  Generally  when  viewed  alone,  data  fields  have 
no  informational  value.  Examples:  Name,  Number,  Angle,  Unit-of- 
Measure . 


2.1.5  Chain.  A  data  chain  is  a  collection  of  data  fields 
that  are  related  in  such  a  manner  that  the  actual  valid  entries 
for  the  data  fields  are  restricted  by  the  entries  in  the 
associated  data  fields  or  the  informational  value  is  only 
understood  when  the  additional  fields  are  available.  Although  on 
a  low-level  the  data  chain  provides  more  information  than  the  sum 
of  its  individual  data  fields.  Examples:  Date-Time-Group  (day  of 
the  month  is  restricted  by  the  month) ,  Range  (distance  is 
effected  by  the  unit  of  measure) ,  Azimuth  (angle  value  is 
restricted  by  unit  of  measure) .  It  should  be  noted  that  many 
times  information  that  could  be  logically  represented  by  a  data 
chain  is  represented  by  a  data  field  and  a  protocol  rule  to 
increase  the  brevity  of  the  transmission.  Examples:  Range  (only 
a  number  is  provided  -  the  protocol  rule  only  allows  the  range  in 
Meters) ,  Azimuth  (only  a  number  is  provided  -  the  protocol  rule 
only  allows  Magnetic) . 

2.1.6  Set.  The  data  set  is  similar  to  the  data  chain  and 
the  following  data  group.  The  set  is  a  higher  collection  of 
related  data  fields  and  chains,  but  provides  more  informational 
value  than  the  fields  and  chains  of  which  it  is  composed.  The 
set  is  not  used  in  many  protocols  as  the  data  group  provides  a 
similar  and  equally  satisfactory  means  of  providing  information. 
The  set  is  used  to  group  collections  of  information  together  and 
to  allow  for  optional  and  conditional  fields  and  chains  of 
information.  In  many  cases  the  set  is  used  to  provide  brevity 
within  the  protocol  documentation.  Rather  than  to  restate  the 
same  list  of  fields  and  chains  repeatedly  in  the  documentation,  a 
set  will  be  created,  named  and  thereafter  referenced.  Example: 
Emitter-Location  (allows  various  means  of  providing  a  location 
and  signifies  that  the  location  information  is  specific  to  an 
emitter) . 
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2.1.7  Group .  A  data  group  is  the  next  higher  logical 
collection  of  data.  As  mentioned  above  the  data  set  provides  a 
similar  capability  to  provide  a  collection  of  related  data.  The 
group  is  composed  of  multiple  fields,  chains  and  sets.  As  the 
term  indicates  the  "group"  groups  related  data.  The  use  of  the 
group  allows  for  conditional  and  optional  fields,  chains  and 
sets.  The  group  organizes  the  fields,  chains  and  sets  to  provide 
additional  information  not  provided  by  its  related  parts.  Unlike 
the  set  the  group  is  normally  allowed  to  contain  multiple 
subordinate  groups.  This  recursive  definition  of  the  group 
allows  a  group  to  provide  a  collection  of  groups,  thereby 
providing  transmission  brevity  when  used  in  conjunction  with 
repeatability  as  discussed  below.  Although  no  known  use  of  a 
group  name  has  been  identified,  the  group  could  be  named  and 
thereafter  referenced  in  the  documentation  to  provide  brevity. 

2.1.8  Message.  A  message  is  the  highest  order  of  related 
data  that  when  viewed  as  a  whole,  provides  more  information  than 
the  individual  parts.  The  message  generally  has  a  specific 
purpose  in  the  documentation  that  also  adds  information.  The 
message  is  composed  of  fields,  chains,  sets  and  groups.  The 
message  is  the  highest  level  of  data  organization.  In  some 
protocols  multiple  messages  can  be  organized  and  transmitted 
together,  however,  no  informational  value  is  added.  The 
simultaneous  transmission  of  multiple  messages  is  used  to 
increase  throughput  only. 

2.1.9  Repeatability.  In  many  protocols  repeataoxt 
fields,  chains,  sets  and  groups  are  provided  to  allow  for  the 
grouping  of  data  which  have  some  data  in  common.  This 
repeatability  of  levels  of  data  provides  a  high  degree  of  brevity 
to  digital  transmissions  thereby  improving  throughput.  As  a  note 
there  are  occurrences  of  repeatability  where  the  whole  message  is 
defined  as  a  group  and  then  made  repeatable.  This  is  the  same  as 
the  transmission  of  multiple  messages.  Although  transmission 
throughput  is  improved  no  additional  information  can  be  provided 
in  this  manner. 

2.1.10  Mandatory.  In  differing  protocols  the  term 
mandatory  is  used  inconsistently,  however,  in  general  it  is  used 
to  indicate  a  need  or  requirement  to  provide  the  data  in  order  to 
make  the  information  understandable.  Mandatory  is  used  with 
every  type  of  field,  chain,  set  or  group  data  and  rules  governing 
this  requirement  are  provided.  Again,  since  rules  govern  the  use 
of  the  mandatory  classification,  these  rules  are  very  difficult 
to  understand  and  implement  unless  they  are  strict  and  allow  no 
exceptions.  In  some  cases  the  term  mandatory  is  misused  when 
further  associated  with  a  subordinate  rule,  such  as,  "Mandatory 
if  the  information  is  available"  and  "Mandatory  if  assigned". 
These  types  of  rules  actually  define  an  optional  use  of  the  data. 
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2.1.11  Optional .  Most  protocols  provide  the  capability  to 
skip  a  field,  chain,  set  or  group  if  the  originator  of  the 
message  desires  to  not  provide  the  data  or  if  the  data  is 
unknown.  The  rules  for  not  providing  data  differ  significantly 
from  protocol  to  protocol. 

2.1.12  Conditional ♦  Some  protocols  provide  rules  that 
express  the  use  of  field,  chain,  set  and  group  data  based  on 
certain  conditions.  Unlike  optional,  which  expresses  an  "if 
known  or  desired"  condition,  the  truly  conditional  data  usually 
bases  the  conditional  use  of  data  on  another  use  of  data.  The 
designation  of  conditional  fields  generally  attempts  to  equate 
information  as  experienced  in  "real-life"  to  the  transmission  of 
data.  Many  protocols  provide  no  conditional  capability,  rather 
depend  on  the  user  to  understand  and  equate  transmitted  data  and 
its  informational  value.  The  use  or  non-use  of  conditional  type 
data  tends  to  be  based  on  three  different  audiences.  The 
implementers  of  a  protocol  tend  to  want  conditional  data,  as  the 
rules  are  easy  to  understand  and  they  are  physically  documented. 
The  configuration  managers  of  a  protocol  tend  not  to  want 
conditional  rules,  as  the  rules  are  difficult  to  document  and 
manage.  The  users  seem  to  fall  in  the  middle  wanting  the 
protocol  to  guide  them  through  the  creation  of  messages,  but  at 
the  same  time  not  preventing  them  from  changing  the  conditions. 
Example:  Emitter-Location  allows  the  user  to  report  locations  as 
fixed,  circular  areas  or  elliptical  areas.  If  the  user  indicates 
a  circular  area,  then  only  a  radius  is  necessary,  however,  if  an 
elliptical  area  is  indicated  then  an  orientation,  major  axis  and 
minor  axis  is  needed.  Conditional  data  provides  a  certain  degree 
of  understanding  of  the  pure  data  to  information  conversion 
thereby  assisting  in  the  consistent  interpretation  of  the  data. 

2.1.13  Fixed-Format.  Some  digital  data  link  protocols 
are  fixed-format  meaning  that  the  fields,  chains,  sets  and  groups 
must  appear  in  a  fixed  order.  Even  if  a  level  of  data  is 
unnecessary  or  not  used,  the  positions  for  the  data  must  appear 
with  some  default  value.  The  transmission  of  unnecessary  data 
creates  a  sizeable  processing  and  throughput  overhead.  For  this 
reason  few  newer  protocols  use  fixed-format  messages. 

2.1.14  Variable-Format .  Newer  digital  data  link 
protocols  are  now  variable-formatted,  meaning  that  only  necessary 
or  available  data  is  transmitted.  If  data  for  a  field,  chain, 
set  or  group  is  not  necessary  or  available,  the  protocol  allows 
the  skipping  of  that  data.  Numerous  schemes  for  variable 
formatting  exist  for  each  level  of  a  message,  however,  the  basic 
underlying  intention  is  that  if  data  is  not  provided,  it  is 
either  unnecessary  to  the  understanding  of  the  data,  or  not 
available  to  the  message  creator. 
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2.1.15  Character-Oriented .  Although  all  digital  data 
link  protocols  encode  data  in  a  binary  (bit  coded)  transmission, 
the  character-oriented  protocols  basically  transmit  all  data 
encoded  like  the  characters  of  a  typewriter.  These  typewriter 
characters  are  then  encoded  into  usually  7  or  8  binary  bits. 

This  orientation  is  based  on  the  use  of  teletype  devices  where 
the  teletype  directly  received  the  transmission  and  printed 
whatever  character  was  represented.  The  use  of  character- 
oriented  protocols  with  computers  creates  a  large  amount  of 
inefficiency  in  the  transmission  of  data.  For  this  reason,  few 
protocols  use  this  orientation  except  as  a  last  resort  for  the 
transmission  of  free-text  data. 

2.1.16  Bit-Oriented.  By  definition  all  digital  data 
links  are  bit-oriented  due  to  the  transmission  of  binary  signals, 
however,  as  used  here  bit-oriented  refers  to  the  protocol  not 
being  a  character-oriented  protocol.  The  degree  of  bit- 
orientation  varies  from  protocol  to  protocol,  but  basically  the 
intent  is  to  encode  data  in  as  few  bits  as  possible.  This 
greatly  increases  the  throughput  efficiency  of  the  data  link.  If 
the  valid  entries  for  a  data  field  allows  only  two  choices,  then 
this  data  field  is  transmitted  as  one  bit.  Generally  for  numeric 
values  the  data  is  transmitted  as  a  binary  (base  2) 
representation  of  the  number,  much  like  the  numbers  used  within  a 
computer.  The  bit  coding  of  data  greatly  increases  the 
efficiency  of  the  transmission,  however,  the  processing  time  for 
conversion  of  the  data  to  make  it  readable  by  humans  increases. 

2.2  Hypothesis  Basis.  In  order  to  properly  transform/convert 
data  from  one  protocol  to  another,  a  reference  point  must  be 
reached  where  the  representation  of  the  data  is  consistent  to 
both  protocols.  Although  many  attempts  have  been  made  at 
interoperability  through  message  format  and  data  format 
conversion  (such  as  existing  Tadil-A  and  Tadil-B  forwarding) , 
this  conversion  process  at  the  Presentation  Layer  requires  a 
significant  amount  of  co-configuration  management  of  the  two 
interfaced  digital  data  links  to  ensure  interoperability.  Data- 
to-data  conversion  requires  that  the  two  protocols  must  generally 
have  a  one-to-one  correspondence  between  the  valid  data  values. 

In  the  case  of  the  Data  Link  Interface  System,  the  number,  types 
and  specifics  about  each  protocol  to  be  interfaced  is  unknown  as 
the  purpose  is  to  interface  multiple  protocols  and  to  be 
adaptable  to  changing  requirements.  No  co-configuration 
management  of  protocols  is  intended  or  expected  in  the 
development  of  the  Data  Link  Interface  System.  As  the  Data  Link 
Interface  System  must  be  virtually  independent  of  data.  The 
result  of  this  initial  analysis  is  that  the  Data  Link  Interface 
System  must  be  based  on  the  very  highest  layer  of  the  model,  the 
Application  Layer,  as  the  lower  protocol  layers  tend  to  restrict 
system  flexibility. 
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2.3  Hypothesis.  Based  on  the  above  understanding  of  digital 
data  link  protocols  in  general,  and  many  specific  protocols 
currently  in  use  today,  the  MiTech  hypothesis  is  that  the  Data 
Link  Interface  System  concept  is  feasible  and  economically 
practical  only  if  the  interface  between  differing  protocols 
occurs  on  a  "real-world"  information  level,  thereby  isolating 
each  protocol  from  the  other  interfaced  protocols.  In  reference 
to  the  Table  2-1  reference  model,  this  is  interfacing  the 
multiple  protocols  at  the  Application  Layer  where  Information 
Transfer  takes  place.  In  addition  to  isolating  each  protocol 
implemented,  other  facets  that  this  concept  allows  are: 

a.  The  upper  layer  isolation  of  a  single  protocol's 
input  from  its  output,  thereby  allowing  differing  versions  of  the 
same  protocol  to  function  independently. 

b.  Since  the  Man-Machine  Interface  (MMI)  into  a  digital 
computer  is  a  digital  data  protocol,  the  Data  Link  Interface 
System,  when  used  as  terminal  equipment,  could  make  available 
multiple  host  system  interfaces  as  if  the  system  interface  was 
another  protocol  (a  generic  user  interface) . 

c.  Since  the  individual  protocols  are  in  general  already 
implemented,  and  the  Data  Link  Interface  System  interfaces  with 
the  individual  protocols  in  the  same  manner  as  the  current 
systems,  much  of  the  hardware  and  lower  layer  software  already 
developed  can  be  readily  identified  for  reuse  in  the  Data  Link 
Interface  System.  This  similarity  of  function  allows  a  Non- 
Developmental  Item  (NDI)  or  Non-Developmental  Software  (NDS) 
approach  feasible. 

2.4  Data  Link  Interface  System  Processing.  As  depicted  in 
Figure  2-1,  the  Data  Link  Interface  System  is  designed  to  be 
extremely  modular  with  as  much  independent  multi-processing 
identified  as  possible.  The  Low-Layer  Interface  Processing 
modules  are  primarily  responsible  for  the  layer-0  through  layer-6 
services.  They  provide  the  same  data  specific  services  for  the 
Data  Link  Interface  System  as  they  currently  provide  for  many 
other  system.  Although  not  depicted  these  modules  must  usually 
interface  with  each  other  to  control  input  and  output  functions. 
The  other  processing  modules  depicted  are  the  actual  heart  of  the 
Data  Link  Interface  System  and  are  responsible  for  conversion  of 
protocol  data  to  "real-world"  information  and  "real-world" 
information  to  protocol  specific  data.  In  addition,  the 
Modification  Information  Update  Processing  and  Message  Generation 
Processing  modules  are  responsible  for  maintaining  the  status  of 
new  information  received  and  determining  which  protocols  and 
messages  should  be  developed  and  transmitted. 
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DATA  LINK  INTERFACE  SYSTEM  (DLIS) 
SUBSYSTEM  PROCESSING  DIAGRAM 

(Not  All  Read  Interfeces  Shown) 


Figure  2-1 


2.5  tAvar  7  -  Application  Tayar  Analysis.  As  discussed  above 
the  feasibility  of  the  Data  Link  Interface  System  depends  to  a 
great  extent  on  the  feasibility  of  a  protocol  independent 
Application  Layer.  The  reasoning  behind  the  determination  of 
feasibility  is  simple,  straight-forward  logic. 

a.  The  intent  of  digital  data  link  communications  is  to 
create  a  pathway  whereby  one  human  can  exchange  information  with 
another  human,  and  upon  receipt,  the  receiving  human  then  has  the 
same  information  as  the  sender.  The  creation  and  implementation 
of  each  data  link  protocol  has  the  purpose  of  providing  this 
pathway.  Since  each  protocol  is  intended  to  be  capable  of 
describing  the  "real-world"  information  in  digital  form  and 
thereby  transferring  this  information  to  the  receiver,  the 
digital  description  must  provide  the  necessary  data  to 
reconstitute  the  information  at  the  receiver. 

b.  The  exchange  of  data  between  humans  and  computers  are 
all  based  on  digital  data  protocols.  The  pressing  of  a  key,  the 
positioning  and  button  press  of  a  mouse,  and  the  finger-on-glass 
selection  from  the  screen  all  result  in  a  digital  input  of  data 
into  the  digital  computer.  The  output  of  data  to  a  screen, 
printer  or  other  digital  device  are  all  based  on  digital  data 
protocols.  Any  of  this  digital  data  could  be  stored  and  used  to 
re-enact  the  stimulus.  The  redirection  of  input  from  a  saved 
file  instead  of  direct  input  from  a  keyboard  is  an  example  of 
this  capability. 

c.  From  the  above,  the  very  existence  of  digital  data 
link  protocols  assumes  that  a  human  can  provide  a  digital  data 
picture  of  "real-world"  information  that  can  be  exchanged.  In 
other  terms  the  digital  data  provides  a  representation  of  the 
information  to  be  exchanged.  The  assumption  that  a  human  can 
provide  a  digital  picture  of  the  information  has  no  effect  on  the 
feasibility  analysis.  If  a  protocol  either  can't  provide  the 
representation  or  provides  an  inaccurate  representation  then  the 
protocol  is  actually  violating  its  primary  purpose.  In  such  a 
case  the  modification  of  the  individual  protocol  to  correct  the 
problem  is  necessary.  In  many  cases  the  information  analysis 
necessary  for  the  development  of  the  Data  Link  Interface  System 
may  identify  many  such  problems. 

d.  Since  this  digital  data  can  be  exchanged  it  can  also 
be  stored,  thereby  saving  the  representation  of  the  information 
for  future  use. 

e.  Each  protocol  that  exchanges  the  same  information 
provides  a  representation  (although  different)  of  the  same 
information. 
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f.  If  two  different  representations  of  the  sane 
information  exists  then  there  is  an  inherent  capability  to 
convert  between  the  two  representations.  This  alone  makes  the 
Data  Link  Interface  System  technically  feasible.  This  may  be  a 
direct  protocol  to  protocol  conversion,  or  the  conversion  may 
require  the  existence  of  interim  representations.  The  direct 
protocol  to  protocol  conversion  would  require  the  exponential 
development  of  an  extremely  large  amount  of  software  to  provide 
individual  protocol  to  protocol  conversion  modules  and  would 
greatly  increase  the  cost  and  decrease  the  maintainability  and 
adaptability  of  the  system.  This  direct  conversion  is  primarily 
a  Presentation  Layer  interface  discussed  earlier  and  is  very 
similar  to  the  methods  currently  used  in  data  forwarding,  such  as 
Tadil-A  to  Tadil-B. 

g.  The  hypothesized  Data  Link  Interface  System  would  use 
the  interim  representation  method  to  store  and  convert  multiple 
protocols  thereby  ensuring  interoperability  and  decreasing  life- 
cycle  cost  and  effort.  In  order  to  further  increase 
maintainability  and  adaptability,  the  interim  representation  used 
within  the  Data  Link  Interface  System  must  effectively  represent 
the  "real-world"  information  and  should  be  generally  independent 
of  the  envisioned  protocol  interfaces. 

2.6  Laver  6  through  0  Analysis.  As  discussed  in  the  basis 
for  the  MiTech  hypothesis,  the  interfacing  of  the  Data  Link 
Interface  System  at  the  Application  Layer  allows  the  system  to 
reuse  the  software  and  hardware  already  implementing  any  protocol 
for  services  below  the  Application  Layer  or  if  necessary  the 
development  process  would  be  comparable  to  any  implementation  of 
the  individual  protocols.  For  this  reason  the  feasibility  of 
satisfying  the  Presentation  Layer  through  Transmission  Media 
Layer  service  requirements  is  only  hindered  by  the  capability  to 
implement  the  specific  protocol.  Since  it  is  assumed  that  the 
desired  protocols  are  implementable,  the  feasibility  of 
implementing  the  protocol  in  the  Data  Link  Interface  System  is 
fundamental . 

2.7  Application  Layer  gantigsuafcLan.  Interface,  as  with  the 
implementation  of  any  protocol,  the  system  must  provide  the 
operator  with  an  interface  to  provide  configuration  data 
necessary  to  the  proper  functioning  of  the  protocol.  For  the 
Data  Link  Interface  System  the  configuration  data  necessary  for 
proper  protocol  use  would  consist  of  a  super  set  of  the 
individual  protocol  configuration  data.  In  addition,  since  the 
purpose  of  the  Data  Link  Interface  System  is  to  provide  protocol 
conversion  without  operator  interaction,  the  system  must  be 
provided  with  the  rules  and  data,  in  table  form,  for  control  of 
the  generation  process.  In  general  this  includes  identification 
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and  correspondence  of  addressee  information,  and  for  each  output 
protocol  there  needs  to  be  a  list  of  valid  messages  for  that  link 
(which  can  also  be  based  on  the  message  format  in  use  or  rules 
for  complex  filtering) . 

2.8.  Generation  Process.  In  order  for  the  Data  Link 
Interface  System  to  be  truly  feasible,  the  overall  process  of 
protocol  conversion  must  be  automated  to  the  greatest  extent 
possible.  This  automatic  generation  process  must  alleviate  the 
operator  interaction  thereby  allowing  the  system  to  function  as 
rapidly  as  possible.  The  utility  of  the  Data  Link  Interface 
System  is  greatly  influenced  by  the  amount  of  operator 
interaction  desired.  The  generic  generation  process  is  fairly 
straight  forward: 

a.  If  the  "real  world"  information  changes,  the  fact 
that  the  specific  information  changed  must  be  stored 
(Modification  Information) , 

b.  Along  with  the  modification  information,  the  source 
of  the  information  must  be  stored  to  prevent  retransmission  to 
the  originator, 

c.  In  addition  to  the  modification  information,  the 
allowed  output  protocols  must  be  indicated.  This  information  is 
usually  set  during  system  configuration. 

d.  The  generation  processes  for  each  protocol  function 
independently  based  on  the  indicators  stored  in  the  Modification 
Information.  These  indicators  tell  the  generation  process  when 
information  has  been  changed  and  therefore  a  message  within  the 
protocol  must  be  produced. 

e.  Once  the  generation  process  is  executed,  the  process 
must  determine  which  message  or  messages  must  be  produced  to  pass 
the  indicated  information  as  output.  This  again  is  determined 
through  the  use  of  preset  configuration  data,  and  can  be  either 
simple  or  extremely  complex. 

f.  When  it  is  so  indicated  that  a  message  must  be 
produced,  the  generation  process  accesses  (read-only)  the  "real- 
world"  information  base  to  produce  the  message  if  possible. 
Depending  on  the  protocol  requirements,  all  of  the  information 
necessary  for  a  particular  message  may  not  be  available.  If  not 
available  the  generation  process  aborts  and  tries  the  next 
possible  message. 

g.  This  try  and  fail  process  continues  until  either  a 
message  is  successfully  produced  or  the  generation  process  has 
exhausted  all  possible  indicated  messages. 
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h.  If  a  message  is  produced,  the  message  is  output  in 
accordance  with  the  lower  layer  protocol  requirements.  Based  on 
the  current  configuration  information,  the  generation  process  can 
then  either  try  to  generate  additional  messages  to  pass  the  same 
information  or  cease  the  generation  process  based  on  the  current 
data. 


i.  If  no  message  can  be  produced,  again  based  on 
operator  selected  configuration  data,  the  generation  process  can 
cease  the  generation  process  of  the  information  can  be  formatted 
into  a  protocol  equivalent  free-text  message,  if  free-text  is 
supported  by  the  transmitting  protocol.  The  latter  is  not  deemed 
a  wise  option  as  very  quickly  the  receiver  of  these  messages 
becomes  overcome  by  messages  requiring  operator  attention,  as 
they  are  human  readable  only  (no  automated  value) . 

f.  Regardless  of  the  message/messages  transmitted  the 
generation  process  must  then  remove  the  modification  information 
indicators  so  that  the  generation  process  can  continue  to  the 
next  updated  information.  In  addition  to  the  removal  of  the 
indicator  that  started  the  generation  process,  the  satisfactory 
production  of  a  message  may  also  clear  other  indicators  that  are 
pending  service  if  additional  updated  information  is  transmitted 
in  the  message. 

g.  Once  all  indicated  output  protocols  have  removed 
their  respective  indicators,  the  modification  information  entry 
can  be  totally  deleted  thereby  completing  all  processing 
necessary  for  the  updated  information. 

h.  As  a  note,  if  information  can't  be  transmitted  due 
to  the  lack  of  necessary  (mandatory)  information  for  a  message 
due  to  protocol  requirements,  the  message  indicators  and 
ultimately  the  modification  information  entry  are  deleted  as  if  a 
message  was  generated.  This  creates  no  problem  as  the  later 
receipt  of  the  lacking  necessary  information  will  trigger  the 
generation  of  the  message  and  the  unpassed  information  will  be 
transmitted  at  that  time. 

2.9  Feasibility  Results.  The  Data  Link  Interface  System  is 
technically  feasible,  and  provides  a  low  risk,  low  life-cycle- 
cost,  and  highly  modular/reusable  solution  to  the 
interoperability  problems  currently  being  experienced  by  the 
Marine  Corps  and  the  Department  of  Defense. 

2.9.1  Low  Risk. 

As  the  Presentation  through  Transmission  Media  layer 
implementation  of  each  protocol  is  similar  to  the  implementation 
of  the  protocol  in  any  current  system,  the  reuse/development  of 
the  individual  protocols  are  identified  as  negligible  risk. 
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As  the  primary  information  storage  subsystem, 
modification  information  storage  subsystem  and  generation 
processing  subsystems  are  very  similar  to  current  command, 
control  and  intelligence  system  implementations,  the  integration 
of  the  Data  Link  Interface  Systems  functional  core  is  basically 
the  proper  interfacing  of  the  three  independent  subsystems. 

2.9.2  Low  Life-Cvcle-Cost . 

As  each  current  host  system  is  independently 
developing  multiple  data  link  protocol  interfaces,  the  one-time 
cost  of  the  reusable  Data  Link  Interface  System  would  be 
comparable  to  or  less  than  any  single  implementation  of  the 
specific  protocols,  but  provide  greater  interoperability. 

As  the  Data  Link  Interface  System  only  interfaces 
with  the  host  system  through  a  single  (or  more  if  desired)  data 
link  protocol,  the  development  of  the  host  system  can  be  totally 
independent  of  the  Data  Link  Interface  System's  environment 
(operating  system,  database  management  system,  language, 
hardware) .  This  allows  the  development  and  maintenance  of  the 
Data  Link  Interface  System  to  proceed  independent  of  the  host 
systems  as  long  as  the  individual  host  system  interface  is 
unaffected.  In  addition  this  allows  the  host  system  to  be 
developed  and  maintained  independent  of  the  types  of  data  link 
protocols  implemented. 

As  the  intent  of  the  Data  Link  Interface  System  is  to 
centralize  the  implementation  and  maintenance  of  data  link 
protocols  in  a  single,  reusable  system,  this  will  allow  for  one 
time,  centralized  maintenance  necessary  to  implement  protocol 
changes.  This  alone  sufficiently  impacts  the  life-cycle-cost  of 
system  maintenance  to  make  the  Data  Link  Interface  System 
economically  feasible.  System  specific  implementations,  as 
developed  today,  require  a  tremendous  effort  and  cost  to  maintain 
interoperability,  and  due  to  the  need  for  simultaneous 
introduction  of  a  change  to  the  field,  the  protocols  can  only  be 
modified  as  fast  as  the  slowest  system  modification.  In 
addition,  as  the  independent  host  system  data  link  protocols  are 
tightly  coupled  to  the  overall  system  requirements,  in  general, 
the  modification  of  the  host  system  makes  the  use  of  older 
versions  of  the  protocols  impossible,  thereby  making  backward 
compatibility  to  older,  exported  systems  impossible. 
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3.  DOCUMENTATION 


3.1  Intermediate  Reports 

a.  Monthly  Technical  and  Fiscal  Report  No.  1 

"Joint  Operations  Interoperability  System  for  Marine 
Corps  C3I  System" 

Contract  No.  DAAL-91-C-0004,CLIN  0002AA 
covering  the  period  1  November  1990  to  30  November 
1990  dated  12  December  1990 

b.  Monthly  Technical  and  Fiscal  Report  No.  2 

"Joint  Operations  Interoperability  System  for  Marine 
Corps  C3I  System" 

Contract  No.  DAAL-91-C-0004,CLIN  0002AA 
covering  the  period  1  December  1990  to  31  December 

1990  dated  14  January  1991 

c.  Monthly  Technical  and  Fiscal  Report  No.  3 

"Joint  Operations  Interoperability  System  for  Marine 
Corps  C3I  System" 

Contract  No.  DAAL-91-C-0004,CLIN  0002AA 
covering  the  period  1  January  1991  to  31  January 

1991  dated  14  February  1991 

d.  Monthly  Technical  and  Fiscal  Report  No.  4 

"Joint  Operations  Interoperability  System  for  Marine 
Corps  C3I  System" 

Contract  No.  DAAL-91-C-0004,CLIN  0002AA 
covering  the  period  1  February  1991  to  28  February 
1991  dated  14  March  1991 

e.  Monthly  Technical  and  Fiscal  Report  No.  5 

"Joint  Operations  Interoperability  System  for  Marine 
Corps  C3I  System" 

Contract  No.  DAAL-91-C-0004,CLIN  0002AA 
covering  the  period  1  March  1991  to  31  March 
1991  dated  14  April  1991 

3.2  Research  source? 

a.  Joint  Pub  6-04.10  "U.S.  Message  Text  Formatting 
Program"  dated  l  October  1990 

b.  "Technical  Interface  Design  Plan  (TIDP)  for  Marine 
Tactical  Systems"  dated  16  July  1987 
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4 .  DEMONSTRATION  MODEL 


4.1  Demons t rat Ion  Objective.  The  second  objective  of  this 
feasibility  analysis  was  to  develop  a  demonstration  model  of  the 
Data  Link  Interface  System.  For  this  demonstration  the  Marine 
Corps'  Marine  Tactical  Systems  (MTS)  protocol  and  the  Joint  U.S. 
Message  Text  Formatting  (USMTF)  protocol  were  interfaced  as 
hypothesized . 

4.2  Message  Formats.  The  following  message  formats  were  used 
in  the  demonstration.  These  messages  were  selected  as  they 
provide  the  opportunity  to  exemplify  the  non-trivial  aspects  of 
the  Data  Link  Interface  System  feasibility. 

a.  MTS:  U075  -  Free-Text  Message 

K403  -  Tactical  Elint  Report  (Intell  Ops) 

K404  -  Tactical  Elint  Report  (Emitter  Location) 
K405  -  Tactical  Elint  (Parametric  Data) 

K446  -  Enemy  Sighting  (SPOT)  Report 
K701  -  Position  Report 

b.  USMTF:  F260  -  System  Reply/Remarks 

C121  -  TACELINT 

4.3  Demonstration  Functions.  The  demonstration  model 
developed,  as  depicted  in  Figure  4-1  and  4-2,  exemplified  the 
following  functions: 

a.  Upon  receipt  of  an  MTS  message  the  automatic 
generation  of  the  proper  USMTF  messages  to  transmit  the 
information  embodied  in  the  MTS  message. 

b.  Upon  receipt  of  a  USMTF  message  the  automatic 
generation  of  the  proper  MTS  messages  to  transmit  the  information 
embodied  in  the  USMTF  message. 

c.  Upon  receipt  of  multiple  MTS  and  USMTF  messages,  the 
automatic  generation  of  the  proper  MTS  and  USMTF  messages  to 
transmit  the  resultant  information  embodied  in  the  received 
messages . 

d.  To  demonstrate  the  feasibility  of  a  host  system 
interface  not  based  on  the  long-haul  wide  area  network  protocols, 
the  demonstration  provided  an  example  of  a  local  interface.  This 
local  interface  was  serviced  by  the  demonstration  system  in  the 
same  manner  (functions)  as  the  above  protocols.  Upon  receipt  of 
singular  or  multiple  MTS  and  USMTF  messages,  the  demonstration 
automatically  generated  the  proper  host  system  communications  to 
transmit  the  resultant  information  embodied  in  the  received 
messages . 


DATA  UNK  INTERFACE  SYSTEM  (DLIS)  DEMONSTRATION  SYSTEM 
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Figure  4-1 


DATA  UNK  INTERFACE  SYSTEM  (DLIS)  DEMONSTRATION  SYSTEM 


MTF  XXX. IN 


e.  To  demonstrate  the  feasibility  of  a  interface  based 
on  two  versions  of  the  same  protocol,  the  demonstration  provided 
an  example  of  an  MTS-to-MTS  and  USMTF-to-USMTF  interface.  This 
is  similar  to  an  MTS-Broadcast  to  MTS-Switched  protocol 
interface.  Upon  receipt  of  singular  or  multiple  MTS  and  USMTF 
messages,  the  demonstration  automatically  generated  the  proper 
same  protocol  communications  to  transmit  the  resultant 
information  embodied  in  the  received  messages. 

4.4  Adaptability  and  Maintainability.  Although  difficult  to 
demonstrate,  the  development  of  the  demonstration  Data  Link 
Interface  System  attempted  to  maximize  the  use  of  data-driven 
processes  thereby  providing  a  more  adaptable,  easy  to  modify 
system.  As  examples: 

4.4.1  List  Files  for  Selection  Type  Fields.  In  both 
protocols  there  are  many  fields  that  offer  the  creator  of  a 
message  a  list  of  valid  entries  and  the  operator  selects  from 
this  list.  In  the  demonstration  system  this  capability  was 
provided  by  implementing  the  lists  as  data  files  and  using  a  very 
small,  generic  software  package  to  provide  the  selection 
capability.  In  this  manner  the  addition,  deletion  or 
modification  of  valid  entries  or  the  addition  or  deletion  of 
entire  lists  only  required  the  modification  of  the  data  file,  no 
software  was  effected.  These  same  data  files  were  used  in  the 
creation,  receive,  update  and  generate  processes,  thereby 
providing  the  capability  to  centralize  the  modification  of  list 
type  fields  to  the  modifications  of  a  single  data  file  entry  in  a 
single  data  file  to  provide  a  consistent  modification  to  the 
particular  protocol  being  modified.  These  same  files  also 
provided  the  conversion  factors  necessary  for  the  conversions  of 
units-of-measure  between  protocols. 

4.4.2  Generic  Subroutines  for  Numeric  Type  Fields.  In 
both  protocols  there  are  many  fields  that  require  the  operator  to 
enter  numeric  type  data.  These  fields  seemed  to  span  the  full 
range  of  what  would  be  desired  in  numeric  input/output 
capabilities.  This  ranged  from  normal  range  constraints  (0  to 
999)  on  values,  to  fixed  length  fields  with  variable  decimal 
digits  (99.999  and  999.99,  but  not  100.999),  fixed  length  fields 
with  leading  integer  zeros  (0099.99),  to  complex  shifting  of 
decimals  prior  to  output  (999.99  ->  99999)  and  then  reverse 
shifting  decimals  upon  receipt  (99999  ->  999.99).  This  was 
further  compounded  by  some  fields  requiring  a  fixed  length  field 
but  also  allowing  the  last  digit  to  be  a  "K"  or  "Mw  to  indicate 
units  of  1000  and  1  million,  but  also  restricted  the  ranges 
allowed  based  on  the  use/nonuse  of  the  qualifier.  All  of  these 
identified  formatting  conventions  had  to  be  taken  into  account  in 
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the  demonstration  system,  and  resulted  in  a  set  of  generic 
subroutines  that  provided  the  desired  formatting  capabilities 
based  on  parameters  passed  by  the  calling  routine.  The  use  of 
these  generic  parameterized  subroutines  supports  the  further  use 
of  data  files  for  driving  message  level  processes. 

4.4.3  Data  Files  for  Chains.  Sets  and  Groups.  Although 
not  as  obvious  as  using  data  files  for  fields,  much  of  the 
processing  for  chains,  sets  and  groups  can  be  data  driven. 
Although  not  independently  driven  in  the  demonstration  model, 
these  syntax  related  protocol  rules  can  be  driven  by  a  mix  of 
data  files  and  generic  subroutines.  In  the  demonstration  model 
the  data  driven  aspects  of  these  syntax  elements  were 
incorporated  in  the  message  level  syntax  processing.  They  should 
be  handled  independently  thereby  allowing  a  more  adaptable  and 
maintainable  solution. 

4.4.4  Data  Files  for  Message  Formats.  As  both  of  the 
protocols  use  message  formats  in  the  syntactic  formatting  of  the 
data  to  be  transmitted,  these  message  formats  are  also  provided 
to  the  system  in  the  form  of  data  files  which  are  used  by  small, 
generic  message  format  processing  subroutines.  As  discussed 
above  the  use  of  chains,  sets  and  groups  should  be  handled  by 
independent  data  files  and  subroutines,  however,  in  the 
demonstration  system  these  syntax  elements  are  handled  at  the 
message  level.  Effectively,  the  current  implementation  can  very 
rapidly  provide  a  new  message  format  by  replication  and 
modification  of  existing  data  files,  without  modification  of  the 
existing  software.  In  addition,  message  formats  can  be  modified 
without  any  impact  on  the  existing  software. 

4.4.5  Data  Files  for  System  Configuration.  Although  not 
unusual  within  a  system,  the  demonstration  system  overall 
functionality  is  driven  by  indicators  stored  in  configuration 
data  files.  Data  such  as  which  messages  to  generate  based  on  the 
changed  information,  the  activation  of  protocol -to-protocol 
allowed  transformations,  and  the  generation  of  free-text  messages 
for  unused  information  are  all  driven  by  data  files.  In  this  way 
the  demonstration  system  can  be  configured  as  a  receive-only 
system  and  incrementally  configured  until  it  has  its  full 
functionality. 
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4.5  Sample  1  Demonstration  Input/Output.  For  this  sample  the 
demonstration  system  was  configured  to  provide  total  protocol 
conversion,  including  USMTF  and  System  output  based  on  USMTF 
input.  When  comparing  the  USMTF  input  message  and  USMTF 
generated  output  message,  note  the  difference  in  the  "EMIiCC"  and 
"PRM"  units-of -measure.  This  is  a  result  of  the  standardization 
of  the  information  base  to  set  units  of  measure.  The  output 
units-of-measure  could  be  configured  to  any  logical  set  based  on 
the  operators  needs  thereby  providing  a  consistent  interface. 

Also  note  that  the  USMTF  "EXER"  and  "COLLINFO"  data  is  not 
transmitted  via  the  MTS  generated  messages.  This  is  a  protocol 
related  restriction,  as  the  MTS  protocol  provides  no  capability 
to  exchange  this  type  of  information  (it  may  exist  in  other  MTS 
messages  not  implemented  in  the  demonstration  model) . 

Input  USMTF  ,,C12l  -  TACELINT"  Message  <24  Created  and  Received: 

OPFAC_2 

0000024 

UNCLAS 

EXER/DLIS  DEMONSTRATION/SCENARIO  1.1// 

MSGID/TACELINT/0PFAC_2/ 000002 4/MAY// 

COLLINFO/ -/ -/-/ DLIS// 

SOI/A0001/010614Z/010715Z/ABCD/EMITTER  0NE/IZ/S9876EZ123499/ENEMY 
UNIT  ONE/SCUD/GM// 

EML0C/-/P/UT: 16TCC09509763/-/359 . 9G/1 . 4KM/800M// 

PRM/-/98 . 7MHZ/D/-/F/PD: 123 . 00 0/TRCK/ -/VERT/ / 


MTS  aifll  -__T3ctlcal  Elint  Report  (Intell  Ops)  Message  *84 
Generated  Md-Tgansalttedi 

—  Bit  Coded  Transmission  — 

( —  Left  is  First  Bit  of  Transmission  — ) 
10000000000100000001001000001000010110001001100001011000100000001 
00000001000000001000000010000000100000001110101100110000011011001 
11100101011011001110111110010001011011010000001101000001100000001 
10000000110001111111101101101100001011001110001101111011011010010 
10111110010001111100110010110110000000101000000111000001100111001 
10100100110001010111001010101101000010010011001000011001111010001 
01111111111001001100101101110011000101001000010000001000110100101 
11100011110100011101110010110100010110110001010011010100011100110 
10010010000101010100000100111110000101111111110101011011000011100 
1010111001000111111111101001010 

—  MTS  Message  Decoded  — 

00000001/084/ROUTINE/UNCLASSIFIED/0000/DLIS  HOST/OPFAC-1/ 
OPFAC-3/ODD  PARITY/ 

NO  REPLY/RESPONSE  REQUIRED/K403/9105230115Z/ 

A0001/9105010715Z/9105010715Z/ABCD/EMITTER  0NE/IZ/9876EZ1234/99/ 
ENEMY  UNIT  ONE/SCUD/GUIDED  MISSILE 


24 


MTS  »K404  -  Tactical  glint  Report  (Emitter  Location) ■  Message  #85 
Generated  and  Transmitted; 


( —  Left  is  First  Bit  of  Transmission  — ) 
10000000000100000001101000001000010110001001100001011000100000001 
00000001000000001000000010000000100000001110101100110000011011001 
10010101011011001110111110010001011011010000001101000001100000001 
10000000110001111111100010001001010101110000100110000010100101001 
110010111110011110101100001000000100101010000100011100010011 

—  MTS  Message  Decoded  — 

000 00001/ 08 5/ROUTINE/UNCLASSIFIED/ 00 00/ DLIS  HOST/OPFAC-1/ 
OPFAC-3/ODD  PARITY/ 

NO  REPLY/RESPONSE  REQUIRED/K404/9105230115Z/ 

A0001/ELLIPTICAL  AREA  OF  PROB.  "ELP/EAP"/16TCC0950097630/ 
0080001400356 

MTS  "K405  -  Tactical  Elint  (Parametric  Data)"  Message  #88 
Generated  and  Transmitted: 

( —  Left  is  First  Bit  of  Transmission  — ) 
10000000000100000001000100001000010110001001100001011000100000001 
00000001000000001000000010000000100000001110101100110000011011001 
11010101011011001110111110010001011011010000001101000001100000001 
10000000110001111111110010011100100011110000100001111001000001011 
01000111100011100000110000011110010000000000 

—  MTS  Message  Decoded  — 

OOOOOOOI/O88/ROUTINE/UNCLASSIFIED/OOOO/DLIS  HOST/OPFAC-1/ 

OPFAC- 3/ODD  PARITY/ 

NO  REPLY/RESPONSE  REQUIRED/K405/9105230115Z/ 

A000 1/98 7 00000/DISCRETE  FREQUENCY/ 

FREQ.  MODULATED  CARRIER  (NONPULSED) /123/ 

TRACKING  (OTHER  THAN  CONICAL/ LOBE) /LINEAR  VERTICAL 

P8MTF  "C121  -  TACELINT"  Message  <93  Generated  and  Transmitted: 

DLIS  HOST 

0000093 

UNCLAS 

EXER/DLIS  DEMONSTRATION/SCENARIO  1.1// 

MSGI D/TACELINT/ DLIS  HOST/ 000009  3/MAY// 

COLLINFO/ -/ -/ -/ DLI S// 

SOI/AOOOl/ 010614 Z/ 0107 15Z/ABCD/EMITTER  ONE/IZ/S9876EZ123499/ENEMY 
UNIT  ONE/SCUD/GM// 

EMLOC/-/P/UT: 16TCC09509763/-/356 . 7T/1400M/800M// 
PRM/-/98700000HZ/D/-/F/PD: 123 . 000/TRCK/-/VERT// 
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GENERIC  systbm  Entity  information  Generated  and  Transmitted: 
(***  indicates  entity  changes  since  last  report) 


ORIGINATOR  OPFAC-2 
SSN  0000024 
MSG_DTG  9105230115Z 
IDENTIFIER  1002 
***  EFF  DTG  9105010715Z 


IDENTIFIER  1002 
***  LOC_TYPE  ELLIPSE 
***  START_DTG  9105010614Z 
***  STOP_DTG  9105010715Z 

***  EMIT_DESIG  EMITTER  ONE 
***  INTENT  ENEMY 

***  LOC_CAT  ELLIPTICAL  AREA  OF  PROB.  "ELP/EAP" 

***  CTRY_SIGHT  IZ 

***  TYPE  OTHER 

***  UNIT_DESGN  ENEMY  UNIT  ONE 

***  SIGNAL_ID  A0001 

***  ELINT_SORT  ABCD 

***  ID_BE  9876EZ1234 

***  BE_SUFFIX  99 

***  WEAPONS  SCUD 

***  EMIT_FUNC  GUIDED  MISSILE 

***  FREQUENCY  98700000  HZ 

***  RF_MODE  DISCRETE  FREQUENCY 

***  PRIACTYCOD  FREQ.  MODULATED  CARRIER  (NONPULSED) 
***  PULSE_DURA  123  uSec 

***  SCAN_TYPE  TRACKING  (OTHER  THAN  CONICAL/LOBE) 

***  ANT_POLAR  LINEAR  VERTICAL 
***  COLL  PRJNM  DLIS 


IDENTIFIER  1002 
***  REL_LOC  16TCC09 50097630 
***  BEARING  356.7  True 
***  MAJOR_AXIS  1400  Meters 
***  MINOR_AXIS  800  Meters 
***  ELLIPSE  800/1400/356.7 


—  MESSAGE  REFERENCE  — 

ORIGINATOR  OPFAC-2 
SSN  0000024 
MSG_DTG  9105230245Z 
SOURCE  MTF 

SECURITY  UNCLASSIFIED 
MSGNUMBER  C121 
REPORT_DTG  9105230245Z 

COMMENTS  TARGET  TYPE:  SIGNAL  IDENTIFIER 
TITLE  C121  -  TACELINT 
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MSG_MONTH  MAY 

EXERCISE  DLIS  DEMONSTRATION 

EXER  ID  SCENARIO  1.1 


—  NEW  MESSAGE  RECEIVED  -- 
ORIGINATOR  OPFAC-2 
SSN  0000024 
MSG_DTG  9105230115Z 
SOURCE  MTF 

SECURITY  UNCLASSIFIED 
MSGNUMBER  Cl 21 
REPORT_DTG  9105230115Z 

COMMENTS  TARGET  TYPE:  SIGNAL  IDENTIFIER 

TITLE  C121  -  TACELINT 

MSG_MONTH  MAY 

EXERCISE  DLIS  DEMONSTRATION 

EXER  ID  SCENARIO  1.1 
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4.6  Sample  2  Demonstration  Input/Output.  For  this  sample  the 
demonstration  system  was  also  configured  to  provide  maximum 
protocol  output.  Note  that  although  the  only  new  information 
received  in  the  MTS  message  was  the  emitters  fixed  location,  the 
messages  generated  provided  additional  data  based  on  the 
information  contained  in  the  information  base  on  emitter  A0001. 

In  the  Generic  System  information  generated,  it  is  anticipated 
that  the  host  would  only  be  provided  the  •****"  data  and  the 
necessary  data  to  identify  the  entity.  Of  particular  note  is  the 
generation  of  the  MTS  K446  -  Enemy  Sighting  (SPOT)  Report.  This 
report  is  generated  when  the  emitter  location  becomes  fixed. 


input  MTS  "K404  -  Tactical  Elint  Repo rttEalt ter  Location!” 
Message  #31  Created  and  Receivedi 

( —  Left  is  First  Bit  of  Transmission  — ) 
10000000110000001110100000001000100000001000000010000000010110001 
00110000101100001110100100110000011011001100101010110110011101100 
00011001011010010000001101000001100000001100000001100011111111000 
10000001010101110000100110000110100101100111111111110001111110000 
0000 

—  MTS  Message  Decoded  — 

00000001/03 1/PRIORITY/UNCLASSIFIED/OOOO/OPFAC-l/DLIS  HOST/ 

EVEN  PARITY/ 

NO  REPLY/RESPONSE  REQUIRED/K404/9105230300Z/ 

A0001/EMITTER  LOCATION  ”FIX"/16TCC0972198300 

OSMTF  "C121  -  TACBLINT"  Message  #96  Generated  and  Transmitted; 

DLIS  HOST 

0000096 

UNCLAS 

MSGID/TACELINT/DLIS  HOST/0000096// 

COLLINFO/-/-/-/DLIS// 

SOI/A0001/010614Z/010715Z/ -/EMITTER  ONE/-/-/-/SCUD/GM// 
EML0C/-/F/UT: 16TCC09729830// 

PRM/-/98700000HZ/D/-/F/PD: 123 . 0 0  0/TRCK/ -/VERT// 

MTS  "K404  -  Tactical  Elint  Report  (Emitter  Location)"  Message  «96 
Generated  and  Transmitted: 

( —  Left  is  First  Bit  of  Transmission  — ) 
10000000100100001110110000001000010110001001100001011000010000000 
10000000100000001110101100110000011011001100101010110110011101100 
00011001011010010000001101000001100000001100000001100011111111000 
10000001010101110000100110000110100101100111111111110001111110000 
0000 
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—  NTS  Message  Decoded  — 

00000001/096/PRIORITY/UNCLASSIFIED/0000/DLIS  H0ST/0PFAC-3/ 

ODD  PARITY/ 

NO  REPLY/RESPONSE  REQUIRED/K404/9 1052303 00Z/ 

A0001/EMITTER  LOCATION  "FIX"/16TCC0972198300 

MTS  WK44<  -  Bneav  sighting  (SPOT)  Report"  Message.  197 
generated  end  Transmitted* 

( —  Left  is  First  Bit  of  Transmission  — ) 
10000000100100001110001000001000010110001001100001011000010000000 
10000000100000001110101100110001011011001101111010110110011101100 
00011001011010001000000110110100110001010110000000010001011010010 
00001001001010001100000010110010001000011001111001001010111000100 
01011010000010001000011001101001001110010101010010101011010011010 
10011010110100011101000000100010110000111101000010001001010001110 
00000011001100111101100100011001101101101111011010001100011101000 
00001101011001101010001011011001101001101010000010011010110010111 
101011000000100011110010101110011110100000011111 

~  MTS  Message  Decoded  — 

00000001/097/PRIORITY/UNCLASSIFIED/0000/DLIS  HOST/OPFAC-3/ 

ODD  PARITY/ 

NO  REPLY/RESPONSE  REQUIRED/K446/9105230300Z/ 

K404  -  TAC  ELINT  (EMITTER/9105230300Z/OTHER/16TCC0972098300/ 
9105230300Z/ENEMY  UNIT  ONE/ 

GENERIC  SYSTEM  Entity  Information  generated  and  Transmitted; 

(***  indicates  entity  changes  since  last  report) 


ORIGINATOR  OPFAC-1 
SSN  031 

MSG_DTG  9105230300Z 
IDENTIFIER  1002 
***  EFF_DTG  9105230300Z 
***  LOCATION  16TCC0972198300 


IDENTIFIER  1002 
***  L0C_TYPE  POINT 

START  DTG  9105010614Z 
STOP_DTG  9105010715Z 
EM1T_DESIG  EMITTER  ONE 
INTENT  ENEMY 

***  L0C_CAT  EMITTER  LOCATION  '•FIX'* 
CTRY_SIGHT  IZ 
TYPE  OTHER 

UNIT_DESGN  ENEMY  UNIT  ONE 
SIGNAL  ID  A0001 
ELINT  SORT  ABCD 
ID  BE”  9876EZ1234 
BE~SUFFIX  99 
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WEAPONS  SCUD 
EMIT_FUNC  GUIDED  MISSILE 
FREQUENCY  98700000  HZ 
RF  MODE  DISCRETE  FREQUENCY 

PRIACTYCOD  FREQ.  MODULATED  CARRIER  (NONPULSED) 
PULSE_DURA  123  uSec 

SCANJTYPE  TRACKING  (OTHER  THAN  CONICAL/LOBE) 
ANT_POLAR  LINEAR  VERTICAL 
COLL  PRJNM  DLIS 


—  MESSAGE  REFERENCE  — 

ORIGINATOR  OPFAC-1 
SSN  031 

MSG_DTG  9105230300Z 
SOURCE  MTS 
PRECEDENCE  PRIORITY 
SECURITY  UNCLASSIFIED 
MSG_NUMBER  K404 
REPORTDTG  9105230300Z 

TITLE  K404  -  TAC  ELINT  (EMITTER  LOCATION) 
RCPT_COMP  NO  REPLY/RESPONSE  REQUIRED 


—  NEW  MESSAGE  RECEIVED  — 

ORIGINATOR  OPFAC-1 
SSN  031 

MSG_DTG  9105230300Z 
SOURCE  MTS 
PRECEDENCE  PRIORITY 
SECURITY  UNCLASSIFIED 
MSGNUMBER  K404 
REPORT_DTG  9105230300Z 

TITLE  K404  -  TAC  ELINT  (EMITTER  LOCATION) 
RCPT_COMP  NO  REPLY/RESPONSE  REQUIRED 
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5.  SUMMARY 


5.1  Feasibility.  The  development  and  fielding  of  a  Data  Link 
Interface  System  that  would  provide  a  modular,  reusable  host 
interface  into  multiple  digital  data  link  protocols  is  completely 
feasible  and  economical  using  existing  technology.  The  system  as 
hypothesized  and  discussed  in  section  2  is  largely  based  on  the 
reuse  of  current  technology  for  lover  layer  functionality  and  a 
totally  software/ data  driven  Application  Layer.  As  the  lower 
layers  are  already  implemented  in  current  systems,  their 
technical  feasibility  is  f undamental .  The  software/data  driven 
Application  Layer,  as  discussed  in  section  2,  physically 
demonstrated  in  the  DLIS  model  and  documented  in  section  4, 
soundly  proves  the  technical  feasibility  of  this  system. 

5.2  Adaptability  and  Maintainability.  As  discussed  in 
sections  2  and  4,  and  demonstrated  in  the  model,  the  concept  of 
interfacing  multiple  protocols  at  the  Application  Layer  of  the 
reference  model  is  the  only  economically  feasible  method  of 
satisfying  the  Data  Link  Interface  System  requirement.  If  the 
development  of  this  system  properly  uses  data  driven  processes  to 
the  maximum  extent  and  places  the  highest  priority  on 
adaptability  and  maintainability,  the  Data  Link  Interface  System 
has  the  capability  to  resolve  most  of  the  interoperability 
problems  experienced  today.  The  additional  use  of  POSIX  and  Ada 
standardization  would  also  increase  the  systems  overall  cost 
savings  and  maintainability.  As  presented  in  the  Data  Link 
Interface  System  concept,  the  modification  of  one  protocol 
shouldn't  necessarily  require  the  modification  of  the  information 
base  and  the  other  interfaced  protocol  implementations.  The 
modification  of  the  DLIS  information  base  should  only  result  from 
the  modification  or  addition  of  information  in  relation  to  the 
"real-world".  To  this  end,  the  Data  Link  Interface  System  should 
be  developed  with  the  maximum  amount  of  "real-world"  user 
involvement  as  possible.  For  this  reason  an  evolutionary 
development  approach  is  recommended,  to  provide  this  constant 
user  involvement,  and  repetitive  validation  of  the  understanding 
of  the  information. 
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6.  CONCLUSION 


* 


6.1  Feasible.  Based  on  the  results  of  this  feasibility 
analysis,  the  realization  of  the  hypothesized  Data  Link  Interface 
System  is  within  the  scope  of  existing  technology,  is  cost 
effective,  and  has  the  potential  of  resolving  most  of  the 
existing  interoperability  problems. 


7 .  RECOMMENDATIONS 

7.1  Continued  Development.  It  is  recommended  that  the 
development  of  this  Data  Link  Interface  System  continue  as 
rapidly  as  possible.  This  development  should  be  based  on  an 
evolutionary  development  strategy  to  provide  maximum  involvement 
of  the  user  community.  The  next  phase  of  development  should  be 
the  development  of  a  brass  board  configuration  that  can  further 
provide  best-practice  answers  for  the  full-scale  development  of 
the  system. 

7.2  Standing  Working  Group.  The  development  and  follow-on 
upgrades  of  the  Data  Link  Interface  System  is  going  to  require 
the  continuous  participation  of  users  of  the  system  information 
and  individuals  experienced  in  the  configuration  management 
processes  of  the  many  different  protocols.  It  is  recommended 
that  a  standing  working  group  of  experienced  users  and  protocol 
experts  be  formed  to  provide  guidance/answers  to  many  of  the 
questions  that  are  going  to  be  produced  by  this  development.  The 
successful  development  of  the  Data  Link  Interface  System  is 
greatly  dependent  upon  the  understanding  of  the  "real-world" 
information  as  exchanged  by  the  data  in  each  interfaced  protocol. 
This  understanding  of  the  information  (what  does  it  mean)  can 
only  be  found  in  current,  experienced  operational  personnel.  In 
addition,  the  protocol  experts  are  needed  to  provide  information 
as  to  why  the  syntax  of  the  protocols  (messages,  groups,  etc.) 
are  implemented  the  way  they  are,  and  if  found  to  be  in  error, 
the  proper  procedures  to  initiate  the  resolution  of  the  problem 
in  the  most  expeditious  manner. 
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